Contributor Experience Charter #2843

parispittman · 2018-10-24T07:10:33Z

Trying this charter thing out again since the mistake during the recent outage merged to master. Ref #2810.

Incorporated most of @spiffxp's review from #2810 except the GitHub management bullets which I'd rather have @cblecker weigh in directly about. Expecting another edit.

cblecker

This looks great. A few comments from me. Really, really, really appreciate all the thought and work you put into this @parispittman 🏆 !

cblecker · 2018-10-24T19:53:37Z

sig-contributor-experience/charter.md

+
+- Establish policies, standards, and procedures:
+  - routine GitHub management tasks, including but not limited to: org membership, org permissions, repo creation/administration.
+  - "Org Owner" GitHub permissions, and grant/limit these privileges accordingly


this line might be redundant with the previous

cblecker · 2018-10-24T19:53:59Z

sig-contributor-experience/charter.md

+  - routine GitHub management tasks, including but not limited to: org membership, org permissions, repo creation/administration.
+  - "Org Owner" GitHub permissions, and grant/limit these privileges accordingly
+  - bot accounts, service accounts, webhooks, and third-party integrations for all communication platforms that we support but most importantly, GitHub.
+- Establishing a "GitHub Administration team" that will oversee the execution of GitHub management tasks: inviting new members to the org, creating repos, executing moderation decisions, auditing permissions.


this may also be redundant

cblecker · 2018-10-24T19:54:13Z

sig-contributor-experience/charter.md

+  - bot accounts, service accounts, webhooks, and third-party integrations for all communication platforms that we support but most importantly, GitHub.
+- Establishing a "GitHub Administration team" that will oversee the execution of GitHub management tasks: inviting new members to the org, creating repos, executing moderation decisions, auditing permissions.
+- Work with other SIGs and interested parties in the project to execute GitHub tasks where required
+-Own and execute events that are targeted to the Kubernetes contributor community, including:


nit: space after dash

cblecker · 2018-10-24T19:55:51Z

sig-contributor-experience/charter.md

+  - The weekly [Kubernetes Community meeting]
+  - [Contributor Summit(s)]
+  - SIG Contributor Experience face to face meetings
+  - [Steering Committee elections] (though we do not own policy creation, see 'out of scope' below)


unclear on what this involves. don't know if this is direct contribex, or is it our responsibility to provide election officers who take this on?

@spiffxp - do you want to shed some light on this from a steering perspective?
I think contribex should own the process as it's a contributor only event and we should influence events that are solely for contributors.

I am comfortable with the phrasing as is, but yes I read this as saying elections officers should come from contribex, as that is the SIG I trust to be most in tune with community norms and processes. The steering committee has often deferred to the officers when it comes to the details of executing the election.

cblecker · 2018-10-24T22:30:32Z

sig-contributor-experience/charter.md

+  - [Group Mentoring - WIP]
+  - [The 1:1 Hour - WIP]
+  - Speed Mentoring at KubeCon
+- Create best practices, trainings, policies, and [moderation] of Kubernetes communication platforms, the transparency vehicles of information throughout the project. This includes user guidelines when the contributor is the user of the platform. Moderation is an always on, never off service that we supply with trusted contributors spanning time zones. This includes immediate action when dealing with code of conduct issues in a public space that are defined below:


This is pretty long for a point form list, and mixes both owning the platforms, and doing moderation on them. Perhaps this can be shortened or split up?

Also, we (via the github admin team) would handle moderation on GitHub too, where that's needed.

I took out some lines - how is this:

Create best practices, trainings, policies, and [moderation] of Kubernetes communication platforms, the transparency vehicles of information throughout the project. We supply the moderation teams that span time zones for 24/7 coverage. This includes immediate action when dealing with code of conduct issues in a public spaces, which are defined below:

much clearer! 👍

parispittman · 2018-11-01T13:32:42Z

@cblecker - i think this leaves creation of subprojects and steering committee election process as the last remaining items to discuss/clear up. Any other feedback?

@spiffxp - we are close!

spiffxp

Sorry for the massive delay in feedback. Shanghai and turkey. I'll be responsive to this now.

A few notes to address; the main thing is I'd like to see a decision on subproject creation. Happy to discuss in a more high bandwidth medium if it would help.

spiffxp · 2018-11-30T03:34:17Z

sig-contributor-experience/charter.md

+
+### In scope
+
+#### Code, Binaries and Services


This reads like a massive and overly specific list. I would prefer to see this summarized and less exhaustively listed, but if you completely ignore this and address the rest of my comments, I won't block.

That said, some suggestions:

I still think this would benefit from consolidating moderation/management of communication platforms into one list as I suggested in the last PR

Consider breaking up the comms / events / services that you offer into:

Community-focused (eg: community meeting, summits, elections, news distro, surveys)

SIG-focused (eg: logistics, best practices, event planning / retrospective support)

Contributor-focused (eg: mentoring, contributor guide)

For some reason project health and automation feel distinct from the above but I can't quantify or come up with a good bullet to lump them under

spiffxp · 2018-11-30T03:35:01Z

sig-contributor-experience/charter.md

+  - engagement on project platforms that we manage
+- Encourage automation to improve productivity for contributors where it makes sense and consult with SIG Testing if automation is covering GitHub workflows.
+- Research other OSS projects and consult with their leaders about contributor experience topics to make sure we are always delivering value to our contributors.
+- Provide retrospective hosting services on request to SIGs


this is already called out above as

Retrospective moderation for other SIGs upon request

spiffxp · 2018-11-30T03:38:35Z

sig-contributor-experience/charter.md

+- The contributor experience for repos not included in the Kubernetes [associated repositories]list.
+- Steering committee election policy updates and maintenance.
+- We do not create SIGs/WGs but can assist in the various community management needs of their micro communities that would kick off their formation and keep them going.
+- We are not the [code of conduct committee] and therefore do not control incident management reporting or decisions; however, our moderation guidelines allow us to act swiftly if there is a clear violation of terms on one of our supported platforms. If there is an action that the committee needs to take that involves one of these platforms (example: the removal of someone from GitHub), we will carry that out if none of the committee members have access.


clear violation of terms

the platform's TOS? our CoC? both?

i put a line about both

spiffxp · 2018-11-30T03:38:53Z

sig-contributor-experience/charter.md

+- We are not the [code of conduct committee] and therefore do not control incident management reporting or decisions; however, our moderation guidelines allow us to act swiftly if there is a clear violation of terms on one of our supported platforms. If there is an action that the committee needs to take that involves one of these platforms (example: the removal of someone from GitHub), we will carry that out if none of the committee members have access.
+- Communication platforms that are out of our scope for maintenance and support but we may still have some influence:
+    - [r/kubernetes]
+    - [kubernetesio@] twitter account


nit: @kubernetesio

spiffxp · 2018-11-30T03:41:44Z

sig-contributor-experience/charter.md

+  - The weekly [Kubernetes Community meeting]
+  - [Contributor Summit(s)]
+  - SIG Contributor Experience face to face meetings
+  - [Steering Committee elections] (though we do not own policy creation, see 'out of scope' below)


I am comfortable with the phrasing as is, but yes I read this as saying elections officers should come from contribex, as that is the SIG I trust to be most in tune with community norms and processes. The steering committee has often deferred to the officers when it comes to the details of executing the election.

spiffxp · 2018-11-30T03:42:53Z

sig-contributor-experience/charter.md

+  - ongoing work with the CNCF to improve [DevStats]
+  - the contributor experience survey(s)
+  - engagement on project platforms that we manage
+- Encourage automation to improve productivity for contributors where it makes sense and consult with SIG Testing if automation is covering GitHub workflows.


If this is collaboration with another SIG then I would recommend putting this in the cross-cutting section

spiffxp · 2018-11-30T03:47:06Z

sig-contributor-experience/charter.md

+- Own and execute events that are targeted to the Kubernetes contributor community, including:
+  - The weekly [Kubernetes Community meeting]
+  - [Contributor Summit(s)]
+  - SIG Contributor Experience face to face meetings


this seems out of place in this list as it's specific to this SIG vs. being community-wide

spiffxp · 2018-11-30T03:59:58Z

sig-contributor-experience/charter.md

+### Subproject Creation - TODO
+Pick one:
+SIG Technical Leads
+Federation of Subprojects


I need to understand what's holding us up in making a decision here. Both options prefer lazy consensus among SIG members first before resorting to a fallback vote.

IMO a large portion of this SIG's responsibilities are non technical in nature, so I'm not sure that the the TL option makes much sense. I would be comfortable expanding the "TL" option to include "TLs and Chairs" in this case, or suggest Federation of Subprojects (which a few SIGs have chosen, notably SIG Cluster Lifecycle). Or we consider "community management" a "technical" skill, and opt to choose a tech lead or two who specializes in that.

I think in our case, Chairs + TLs is the best option. Still gives a wide perspective, but in practice, we've never needed a tie break.. consensus of the body is always best.

updated with chairs and tls

cblecker · 2018-12-06T20:54:16Z

I'm good with all of @spiffxp's feedback above.

idealhack

this charter is really comprehensive. just some nits:

idealhack · 2019-01-04T16:12:27Z

sig-contributor-experience/charter.md

+
+- Deploying Changes:
+  When implementing policy changes we strive to balance  responding quickly to the needs of the community and ensuring a disruption-free experience for project contributors. As such, the amount of notice we provide and the amount of consensus we seek is driven by our estimation of risk. We don't measure risk objectively at this time, but estimate it based on these parameters:
+  - Low risk changes impact a small number (<4) of SIGs, WGs, or repos, do not break existing contributor workflows, and are easy to roll back. When implementing low risk changes we:


Suggested change

- Low risk changes impact a small number (<4) of SIGs, WGs, or repos, do not break existing contributor workflows, and are easy to roll back. When implementing low risk changes we:

- Low-risk changes impact a small number (<4) of SIGs, WGs, or repos, do not break existing contributor workflows, and are easy to roll back. When implementing low-risk changes we:

idealhack · 2019-01-04T16:12:36Z

sig-contributor-experience/charter.md

+- Code for the testing and CI infrastructure - that’s SIG Testing
+- [kubernetes/community]  ownership of folders for KEPs and Design Proposals. Members are to follow those folders owners files and SIG leadership for the specific issue/PR in question.
+- User community management. We hold office hours because contributors are a large portion of the volunteers that run that program.
+- The contributor experience for repos not included in the Kubernetes [associated repositories]list.


Suggested change

- The contributor experience for repos not included in the Kubernetes [associated repositories]list.

- The contributor experience for repos not included in the Kubernetes [associated repositories] list.

idealhack · 2019-01-04T16:12:54Z

sig-contributor-experience/charter.md

+  - Low risk changes impact a small number (<4) of SIGs, WGs, or repos, do not break existing contributor workflows, and are easy to roll back. When implementing low risk changes we:
+    - Socialize on kubernetes-sig-contribex@googlegroups.com and on our weekly update calls
+    - We will go to each lead, their mailing lists, slack channel, and/or their update meetings and ask for feedback and a [lazy consensus] process. We will follow up with a post to [kubernetes-dev@]googlegroups.com mailing list
+  - High risk changes impact a large number (<4) of SIGs, WGs, or repos, break existing contributor workflows, and are not easy to roll back. When implementing high risk changes we:


Suggested change

- High risk changes impact a large number (<4) of SIGs, WGs, or repos, break existing contributor workflows, and are not easy to roll back. When implementing high risk changes we:

- High-risk changes impact a large number (<4) of SIGs, WGs, or repos, break existing contributor workflows, and are not easy to roll back. When implementing high-risk changes we:

idealhack · 2019-01-04T16:14:17Z

sig-contributor-experience/charter.md

+- Our standard time box is 72 business hours; however, there may be situations where we need to act quickly but the time period will always be clear and upfront.
+
+If we need funding for any reason, we approach [CNCF].
+CNCF in many of the noted cases above, contributes funding to our platforms, processes, and/or programs. They do not play a day-to-day operations role and have bestowed that to our community to run as we see fit. Since they do fund some of our initatives, this means that they hold owner account privileges on certain platforms like Zoom and Slack. In these cases, such as Slack, there are at least two Contributor Experience [communication] subproject OWNERs listed as admins.


Suggested change

CNCF in many of the noted cases above, contributes funding to our platforms, processes, and/or programs. They do not play a day-to-day operations role and have bestowed that to our community to run as we see fit. Since they do fund some of our initatives, this means that they hold owner account privileges on certain platforms like Zoom and Slack. In these cases, such as Slack, there are at least two Contributor Experience [communication] subproject OWNERs listed as admins.

CNCF in many of the noted cases above, contributes funding to our platforms, processes, and/or programs. They do not play a day-to-day operations role and have bestowed that to our community to run as we see fit. Since they do fund some of our initiatives, this means that they hold owner account privileges on certain platforms like Zoom and Slack. In these cases, such as Slack, there are at least two Contributor Experience [communication] subproject OWNERs listed as admins.

idealhack · 2019-01-04T16:17:36Z

sig-contributor-experience/charter.md

+We cross-cut all SIGs and WGs to deliver the following processes:
+
+- Deploying Changes:
+  When implementing policy changes we strive to balance  responding quickly to the needs of the community and ensuring a disruption-free experience for project contributors. As such, the amount of notice we provide and the amount of consensus we seek is driven by our estimation of risk. We don't measure risk objectively at this time, but estimate it based on these parameters:


Suggested change

When implementing policy changes we strive to balance responding quickly to the needs of the community and ensuring a disruption-free experience for project contributors. As such, the amount of notice we provide and the amount of consensus we seek is driven by our estimation of risk. We don't measure risk objectively at this time, but estimate it based on these parameters:

When implementing policy changes we strive to balance responding quickly to the needs of the community and ensuring a disruption-free experience for project contributors. As such, the amount of notice we provide and the amount of consensus we seek is driven by our estimation of risk. We don't measure risk objectively at this time, but estimate it based on these parameters:

idealhack · 2019-01-04T16:18:13Z

sig-contributor-experience/charter.md

+- Deploying Changes:
+  When implementing policy changes we strive to balance  responding quickly to the needs of the community and ensuring a disruption-free experience for project contributors. As such, the amount of notice we provide and the amount of consensus we seek is driven by our estimation of risk. We don't measure risk objectively at this time, but estimate it based on these parameters:
+  - Low risk changes impact a small number (<4) of SIGs, WGs, or repos, do not break existing contributor workflows, and are easy to roll back. When implementing low risk changes we:
+    - Socialize on kubernetes-sig-contribex@googlegroups.com and on our weekly update calls


Suggested change

- Socialize on kubernetes-sig-contribex@googlegroups.com and on our weekly update calls

- Socialize on kubernetes-sig-contribex@googlegroups.com and our weekly update calls

idealhack · 2019-01-04T16:24:21Z

sig-contributor-experience/charter.md

+  - High risk changes impact a large number (<4) of SIGs, WGs, or repos, break existing contributor workflows, and are not easy to roll back. When implementing high risk changes we:
+    - Socialize on kubernetes-sig-contribex@googlegroups.com and on our weekly update calls
+    - Seek [lazy consensus] with a time box of at least 72 business hours with a GitHub issue link (or proposal if not applicable) to the following mailing lists:
+    - [kubernetes-sig-contribex@]googlegroups.com


Suggested change

- [kubernetes-sig-contribex@]googlegroups.com

- [kubernetes-sig-contribex@]googlegroups.com

idealhack · 2019-01-04T16:24:40Z

sig-contributor-experience/charter.md

+    - Socialize on kubernetes-sig-contribex@googlegroups.com and on our weekly update calls
+    - Seek [lazy consensus] with a time box of at least 72 business hours with a GitHub issue link (or proposal if not applicable) to the following mailing lists:
+    - [kubernetes-sig-contribex@]googlegroups.com
+    - sig-leads@googlegroups.com


Suggested change

- sig-leads@googlegroups.com

- sig-leads@googlegroups.com

idealhack · 2019-01-04T16:24:51Z

sig-contributor-experience/charter.md

+    - Seek [lazy consensus] with a time box of at least 72 business hours with a GitHub issue link (or proposal if not applicable) to the following mailing lists:
+    - [kubernetes-sig-contribex@]googlegroups.com
+    - sig-leads@googlegroups.com
+    - [kubernetes-dev@]googlegroups.com with the GitHub issue link including the subject [NOTICE]: $announcement


Suggested change

- [kubernetes-dev@]googlegroups.com with the GitHub issue link including the subject [NOTICE]: $announcement

- [kubernetes-dev@]googlegroups.com with the GitHub issue link including the subject [NOTICE]: $announcement

indent these three mailing lists

idealhack · 2019-01-04T16:28:46Z

sig-contributor-experience/charter.md

+    - Socialize on kubernetes-sig-contribex@googlegroups.com and on our weekly update calls
+    - We will go to each lead, their mailing lists, slack channel, and/or their update meetings and ask for feedback and a [lazy consensus] process. We will follow up with a post to [kubernetes-dev@]googlegroups.com mailing list
+  - High risk changes impact a large number (<4) of SIGs, WGs, or repos, break existing contributor workflows, and are not easy to roll back. When implementing high risk changes we:
+    - Socialize on kubernetes-sig-contribex@googlegroups.com and on our weekly update calls


the same with low-risk ones?

if so:

Suggested change

- Socialize on kubernetes-sig-contribex@googlegroups.com and on our weekly update calls

- Socialize on kubernetes-sig-contribex@googlegroups.com and our weekly update calls

parispittman · 2019-01-04T20:18:11Z

/cc @sarahnovotny

nikhita

Some nits, but this looks so detailed and awesome, Paris!! 💯

nikhita · 2019-01-04T20:26:19Z

sig-contributor-experience/charter.md

+[DevStats]: https://k8s.cncf.devstats.io
+[kubernetes-sig-contribex@]: https://groups.google.com/forum/#!forum/kubernetes-sig-contribex
+[kubernetes blog]: https://www.kubernetes.io/blog
+[GitHub]: https://git.k8s.io/community/github-management


nit: let's call this github-management instead of just GitHub? 😬

nikhita · 2019-01-04T20:28:07Z

sig-contributor-experience/charter.md

+[project list]: https://github.com/orgs/kubernetes/projects/1
+[Kubernetes Community meeting]: https://git.k8s.io/community/
+[mentoring programs]: https://git.k8s.io/community/mentoring
+[Steering Committee elections]: https://git.k8s.io/community/


I think this should point to https://git.k8s.io/community/events/elections

nikhita · 2019-01-04T20:31:44Z

sig-contributor-experience/charter.md

+  - [Group Mentoring - WIP]
+  - [The 1:1 Hour - WIP]
+  - Speed Mentoring at KubeCon
+We supply the moderation teams that span time zones for 24/7 coverage. This includes immediate action when dealing with code of conduct issues in a public spaces


Is this for the speed mentoring session or in general? If in general, this needs to go as a sub-point under moderation, or else it renders with the Speed Mentoring point.

Maybe we can rephrase this as We supply moderation teams spanning multiple time zones for 24/7 coverage.?

s/a public spaces/public places.

nikhita · 2019-01-04T20:32:33Z

sig-contributor-experience/charter.md

+  - [The 1:1 Hour - WIP]
+  - Speed Mentoring at KubeCon
+We supply the moderation teams that span time zones for 24/7 coverage. This includes immediate action when dealing with code of conduct issues in a public spaces
+- Help onboard new contributors and current into the culture, workflow, and CI of our contributor experience through the [contributor guide], other related documentation, [contributor summits] and programs tailored to onboarding.


nit: s/new contributors and current/new and current contributors

nikhita · 2019-01-04T20:34:24Z

sig-contributor-experience/charter.md

+- Perform issue triage on and maintain the [kubernetes/community] repository.  
+- Help SIGs with being as transparent and open as possible through creating best practices, guidelines, and general administration of YouTube, Zoom, and our mailing lists where applicable
+- Assist SIGs/WG Chairs and Technical Leads with organizational management operations as laid out in the [sig-governance] doc
+- Distribute contributor related news on various Kubernetes channels, including Cloud Native Compute Foundation [CNCF] for posting blogs, social media, and other platforms as needed.


nit: s/[CNCF]/([CNCF]) ... i.e. CNCF in brackets

nikhita · 2019-01-04T20:36:43Z

sig-contributor-experience/charter.md

+  - Low-risk changes impact a small number (<4) of SIGs, WGs, or repos, do not break existing contributor workflows, and are easy to roll back. When implementing low-risk changes we:
+    - Socialize on kubernetes-sig-contribex@googlegroups.com and our weekly update calls
+    - We will go to each lead, their mailing lists, slack channel, and/or their update meetings and ask for feedback and a [lazy consensus] process. We will follow up with a post to [kubernetes-dev@]googlegroups.com mailing list
+  - High-risk changes impact a large number (<4) of SIGs, WGs, or repos, break existing contributor workflows, and are not easy to roll back. When implementing high-risk changes we:


>4 instead of <4

nikhita · 2019-01-04T20:38:24Z

sig-contributor-experience/charter.md

+[CNCF]: https://cncf.io
+[GitHub issues]: https://github.com/kubernetes/community/issues
+[project list]: https://github.com/orgs/kubernetes/projects/1
+[Kubernetes Community meeting]: https://git.k8s.io/community/


This could point to communication#weekly-meeting

nikhita · 2019-01-04T20:41:23Z

sig-contributor-experience/charter.md

+- Code for the testing and CI infrastructure - that’s SIG Testing
+- [kubernetes/community]  ownership of folders for KEPs and Design Proposals. Members are to follow those folders owners files and SIG leadership for the specific issue/PR in question.
+- User community management. We hold office hours because contributors are a large portion of the volunteers that run that program.
+- The contributor experience for repos not included in the Kubernetes [associated repositories] list.


This needs a link to be mentioned below in the doc.

https://git.k8s.io/community/github-management/kubernetes-repositories.md#associated-repositories

nikhita · 2019-01-04T20:45:44Z

sig-contributor-experience/charter.md

+
+### Additional responsibilities of Chairs
+
+Chairs SHOULD plan at least one face to face Contributor Experience meeting per year


dims · 2019-01-07T18:34:15Z

/lgtm
/hold

Please release hold when you wish. Charter looks good!

spiffxp · 2019-01-07T19:39:49Z

/approve

parispittman · 2019-01-07T20:13:18Z

waiting for @sarahnovotny's final go and then I'll release the hold

sarahnovotny · 2019-01-15T19:53:26Z

/approve

k8s-ci-robot · 2019-01-15T19:53:37Z

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: cblecker, parispittman, sarahnovotny, spiffxp

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

~~sig-contributor-experience/OWNERS~~ [cblecker,parispittman,sarahnovotny,spiffxp]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

sarahnovotny · 2019-01-15T19:54:25Z

/hold cancel

parispittman added sig/contributor-experience Categorizes an issue or PR as relevant to SIG Contributor Experience. committee/steering Denotes an issue or PR intended to be handled by the steering committee. labels Oct 24, 2018

parispittman requested review from cblecker and Phillels October 24, 2018 07:10

k8s-ci-robot added do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. size/L Denotes a PR that changes 100-499 lines, ignoring generated files. cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. labels Oct 24, 2018

parispittman force-pushed the charterv3 branch from 37cc3c3 to 7dcb40b Compare October 24, 2018 07:17

cblecker reviewed Oct 24, 2018

View reviewed changes

jdumars mentioned this pull request Oct 29, 2018

Charters Meta-issue kubernetes/steering#31

Closed

parispittman force-pushed the charterv3 branch 3 times, most recently from 125db40 to b9ff339 Compare November 1, 2018 13:30

spiffxp reviewed Nov 30, 2018

View reviewed changes

parispittman force-pushed the charterv3 branch from b9ff339 to 1e1db92 Compare January 4, 2019 02:27

k8s-ci-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Jan 4, 2019

idealhack reviewed Jan 4, 2019

View reviewed changes

parispittman force-pushed the charterv3 branch from 1e1db92 to 07a0240 Compare January 4, 2019 18:54

nikhita reviewed Jan 4, 2019

View reviewed changes

parispittman self-assigned this Jan 5, 2019

charter v3

96e589e

parispittman force-pushed the charterv3 branch from 07a0240 to 96e589e Compare January 7, 2019 18:16

dims changed the title ~~[WIP] Contributor Experience Charter~~ Contributor Experience Charter Jan 7, 2019

k8s-ci-robot removed the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Jan 7, 2019

k8s-ci-robot assigned dims Jan 7, 2019

k8s-ci-robot added do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. lgtm "Looks good to me", indicates that a PR is ready to be merged. labels Jan 7, 2019

cblecker approved these changes Jan 7, 2019

View reviewed changes

k8s-ci-robot removed the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Jan 15, 2019

k8s-ci-robot merged commit 8aa34f3 into kubernetes:master Jan 15, 2019

parispittman deleted the charterv3 branch October 11, 2019 01:36

	- Low risk changes impact a small number (<4) of SIGs, WGs, or repos, do not break existing contributor workflows, and are easy to roll back. When implementing low risk changes we:
	- Low-risk changes impact a small number (<4) of SIGs, WGs, or repos, do not break existing contributor workflows, and are easy to roll back. When implementing low-risk changes we:

	- The contributor experience for repos not included in the Kubernetes [associated repositories]list.
	- The contributor experience for repos not included in the Kubernetes [associated repositories] list.

	- High risk changes impact a large number (<4) of SIGs, WGs, or repos, break existing contributor workflows, and are not easy to roll back. When implementing high risk changes we:
	- High-risk changes impact a large number (<4) of SIGs, WGs, or repos, break existing contributor workflows, and are not easy to roll back. When implementing high-risk changes we:

	When implementing policy changes we strive to balance responding quickly to the needs of the community and ensuring a disruption-free experience for project contributors. As such, the amount of notice we provide and the amount of consensus we seek is driven by our estimation of risk. We don't measure risk objectively at this time, but estimate it based on these parameters:
	When implementing policy changes we strive to balance responding quickly to the needs of the community and ensuring a disruption-free experience for project contributors. As such, the amount of notice we provide and the amount of consensus we seek is driven by our estimation of risk. We don't measure risk objectively at this time, but estimate it based on these parameters:

	- Socialize on kubernetes-sig-contribex@googlegroups.com and on our weekly update calls
	- Socialize on kubernetes-sig-contribex@googlegroups.com and our weekly update calls

	- [kubernetes-sig-contribex@]googlegroups.com
	- [kubernetes-sig-contribex@]googlegroups.com

	- [kubernetes-dev@]googlegroups.com with the GitHub issue link including the subject [NOTICE]: $announcement
	- [kubernetes-dev@]googlegroups.com with the GitHub issue link including the subject [NOTICE]: $announcement


		### Additional responsibilities of Chairs

		Chairs SHOULD plan at least one face to face Contributor Experience meeting per year

Contributor Experience Charter #2843

Contributor Experience Charter #2843

Conversation

parispittman commented Oct 24, 2018

cblecker left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

parispittman commented Nov 1, 2018

spiffxp left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

cblecker commented Dec 6, 2018

idealhack left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

parispittman commented Jan 4, 2019 • edited Loading

nikhita left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

parispittman commented Jan 4, 2019 •

edited

Loading